\chapter{Part D - Implementing the Wiki client}
%\begin{enumerate}
%\item When issuing a GET request to Read with word and Wiki parameters the resulting document should be a valid %xhtml document presenting the corresponding wiki document from the corresponding wiki server.
%\item When issuing a GET request to Edit with word and Wiki parameters the resulting document should be a valid %xhtml form that allows users to edit the contents of the Wiki page corresponding to the selected W	iki document and %wiki server.
%\item When issuing a GET request to Entry the resulting document should be valid xhtml providing access to all the %wiki documents from all the servers. 
%\end{enumerate}


The requirements given when coding the Wiki client provides a set of rules and features that must be maintained. While this presents rather strict requirements that the wiki client must meet, what is more interesting is what is not defined here. There is no telling on how the \texttt{XHTML} document is to be created, the design of the document, the precise content of the document nor how the navigation between different wiki documents is to be performed. This is where we can point all our creative freedom to ease the navigation, editing, and second in priority, for a beautiful presentation. 

\section{Read}
\begin{quotation}
Issuing a GET request to \url{http://foo.daimi.au.dk:xyz/Wiki/Read?wiki=bar}\& \url{word=baz} will result in an XHTML document that shows the contents of the Wiki page corresponding to the word baz on the Wiki server with name bar in the Wiki metaserver.
\end{quotation}

The implementation of the Read feature falls in various steps: 
\begin{enumerate}
\item The way of implementing how the design of the resulting \texttt{XHTML} document is to be produced.
\item Provide navigation between different Wiki documents of the various servers.
\item Provide error handling when requesting a non existing Wiki document and / or on a non existing Wiki server. 
\end{enumerate}

We have implemented all the design in the \texttt{XSLT} transformation stylesheet. When encountering the Wiki root element in the Wiki document the \texttt{XHTML} output begins and adds the different views of the WikiXML document at the appropriate locations. We are working with 2 different views: The main Wiki document and for ease of navigation a list of related wiki pages is provided. 

There are both advantages and disadvantages in the decision of integrating the design in the XSLT stylesheet. Primarily this means that all modification of the Wiki document is to be made by scanning XML documents with the various classes of the SAXON and JDOM frameworks and adding new elements to the appropriate spots. 

In retrospective this is not the optimal solution. The stylesheet should, as the name \texttt{WikiXML2XHTML.xsl} indicate solely transform the WikiXML documents into XHTML and not be in charge of outputting the appropriate design. However the solution we have chosen is valid and does not necessarily yield errors and the improvement would have been mainly in the beauty of the code. 

Now we would, however, have chosen to seperate the design and WikiXML transformation. Primarily the \texttt{XHTML} skeletton would have been in a seperate file. This would enable testing the transformation in isolation and supply an error page. 

If a link to a nonexisting Wiki page is followed you are redirected to create that wiki page with an error message and a list of Wiki documents on the selected server. Once a nonexisting Wiki server is queried you are automatically transferred to the \texttt{Entry} page so that you can find the Wiki server you were in fact looking for. 

For navigation we have implemented 2 main features. The \texttt{Entry} page provides a list to all the Wiki documents on all the servers. This is the gateway to the wonderful universe of Wiki pages created by the students of dWebTek 2008. Once a document have been selected a link to all the Wiki documents on that server along with a list of all related Wiki documents is listed in the menu on the right. 

Ofcourse there are a lot of details in the navigation that are implemented but not listed here. An example is that after saving an edited Wiki page the browser is automatically transferred to reading that Wiki document. 

\begin{lstlisting}
Implement a Wiki client, using Servlets, JSP, JDOM, and XSLT. The implementation will be evaluated on features such as
* Basic functionality. 
* Validity of the generated output. 
* Robustness and fault tolerance. 
* Design, structure, and elegance of the implementation. 
* Quality of the interaction design.

Explain the design and structure of your implementation and known limitations
(for example, that certain functionality is not working properly). Note that there are many ways to attack this part of the project - you are encouraged to comment on alternative approaches and motivate the choices you have made.
\end{lstlisting}

\section{Edit}

\begin{quotation}
Issuing a GET request to \url{http://foo.daimi.au.dk:xyz/Wiki/Edit?wiki=bar}\& \url{word=baz} will result in an XHTML form that allows the user to edit the contents of the Wiki page corresponding to the word baz on the Wiki server with name bar in the Wiki metaserver.
\end{quotation}

Again we find a freedom in maintaining the demand. The means to find the \texttt{Edit} is specified but there is no specification in how the \texttt{PUT} request with WikiXML in the body the server can handle must generated. 

Here we really see the drawbacks of the solution chosen for generating the \texttt{XHTML} page. In order to follow the same path we must implement the design of the Edit page in the \texttt{WikiXML2Txt.xsl} stylesheet. There are several serious drawbacks for that choise. Primarily we have a multiple maintenance problem with two different pieces of code generating a very similar output. Secondly the beauty of the code is again in question. We have chosen a stylesheet named \texttt{WikiXML2Txt.xsl} to generate the design of the \texttt{Edit} page. 

A change in these solutions would without doubt have been a primary objective if the deadline had been a week from now. Seperating the \texttt{XHTML} code in a unique document could have yielded a both smart solution with compact and easy-to-understand code and changes in the \texttt{XHTML} document would affect every webpage generated by our Wiki client. 

For implementing the \texttt{Edit} feature we have chosen a solution with an intermediary \texttt{POST} request to \texttt{Edit} with the text version of the edited WikiXML page in a content parameter, hidden input of wiki and word parameters for the name of the Wiki server and the word. The WikiTXT of the content parameter is translated using the provided \texttt{Txt2WikiXML} java class. 

The WikiXML returned is written in the body of the \texttt{PUT} request using a \texttt{XMLOuputter} with the WikiXML document and the \texttt{OutputStream} from the connection to \texttt{Server}. If errorcode 200 is returned from the request the browser is redirected to read the edited document. Else something went wrong and the exception is printed out. That is, however, not a very clear error message to the standard user, and given more time the exception should be either parsed into seperate incidents such as server not responding, invalid WikiXML etc. but that is a feature yet to be implemented or just rewritten into a general excuse returning the input to the user. 

\section{Entry}

\begin{quotation}
Issuing a GET request to \url{http://foo.daimi.au.dk:xyz/Wiki/Entry} will result in a XHTML document that provides access to all Wiki pages on all Wiki servers in the Wiki metaserver (using lists or search facilities, or both).
\end{quotation}

This time the path chosen in presenting Wiki documents actually provide an easy way to implement. The WikiXML document we must create to present all the servers and documents follow pretty obviously from the results when queriyng the metaserver and various servers. All we need to do is to put them together and assure the result is valid WikiXML, then the \texttt{XSLT} stylesheet \texttt{WikiXML2XHTML} provides the design. 

There are a few notes in the implementation of the \texttt{Entry} feature. This time we use \texttt{setConnectionTimeout} to assure that each server only has 200 miliseconds to respond before moving on to the next server. Therefore we reduce the loadtime of \texttt{Entry} from 30 seconds to less than 4 seconds by skipping all the inactive servers. 

\section{Shortcomings in the Wiki client}

There are a few shortcomings in the Wiki client all a result of the unfair time preassure. Normally when a webpage of this extend is developed several weeks or maybe months are allocated to the perfection of the webservice as complete error checking is a tedious task and the mere writing of an application of this site is a very time-consuming task. 

One of the places where we need to focus is in handling of non-standard characters such as the danish letters \ae , \o  or \aa  and the HTML special characters <, > etc.

We would very much have liked to experiment with a version control feature of the different XML documents. We already use version control to synchronize and collaborate the text and code we are writing and hence we have ideas of how to implement it. In the ideal world each WikiXML document should have a connected XML document with a list of changes each having a linenumber attribute and previous version and next version elements so that traversing between the different versions could be come easy and efficient. 

